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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 



Endorsement notice 



The elements of Internet Engineering Task Force Internet Draft draft-ietf-sigtran-sua-14 [3], apply with the following 
modifications. 



Introduction 



The present document records the changes to the Internet Engineering Task Force (IETF) draft SUA document. IETF 
drafts are transient documents, eventually the SUA draft is expected to be replaced with an RFC, which will persist on 
the IETF website. However, ETSI will keep a copy of the IETF draft on its website until the present document is 
replaced. See [3] below for more information. 
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Scope 



The present document is applicable to the international network and does not intend to restrict national networks. 
However to facilitate interworking, its adoption within national networks is preferred. 

The present document specifies the Signalling Connection Control Part (SCCP) User Adaptation layer signalling 
protocol for connecting SCCP Users via Signalling System No. 7 SCCP international relay points and signalling 
gateways to SCCP Users in an Internet Protocol (IP) managed network. 

The present document endorses and constrains where relevant the SIGTRAN SUA of [3]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[ 1 ] ETSI EN 300 009- 1 : "Signalling Connection Control part (SCCP) (connectionless and connection- 

oriented) to support international interconnection". 

[2] ETSI EN 300 008-1: "Integrated Services Digital Network (ISDN); Signalling System No.7; 

Message Transfer Part (MTP) to support international interconnection; Part 1 : Protocol 
specification [ITU-T Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707 and 
Q.708 modified] ". 

[3] IETF Internet Draft draft-ietf-sigtran-sua-14: "Signalling Connection Control Part User Adaptation 

Layer (SUA)". 

NOTE: At http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-14.txt . 

[4] ITU-T Recommendation Q.714: "Specifications of Signalling System No. 7, Signalling connection 

control part procedures". 

[5] ETSI EG 201 693: "Integrated Services Digital Network (ISDN); Signalling System No.7; Master 

list of codepoints". 

[6] ITU-T Recommendation Q.704: "Specifications of Signalling System No. 7, Message Transfer 

Part, Signalling network functions and messages". 

[7] ITU-T Recommendation Q.711: "Signalling System No.7 - Functional Description of the 

Signalling Connection Control Part". 

[8] ITU-T Recommendation Q.713: "Signalling connection control part formats and codes". 

[9] ITU-T Recommendation Q.774: "Transaction capabilities procedures". 

[10] ETSI TS 102 144: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN; SCTP". 

[11] ETSI TS 102 141: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Transport of SS7 over IP); Message transfer part 2 User Adaptation layer (M2UA) 
[Endorsement of RFC 3331 (2002), modified] 
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[12] 

[13] 
[14] 



ETSI TS 102 142: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 
and SIGTRAN (Messag of SS7 over IP); Message transfer part 3 User Adaptation layer (M3UA) 
[Endorsement of RFC 3332 (2002), modified] 

IETF RFC 3332 (2002): "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User 
Adaptation Layer (M3UA)", G. Sidebottom, K. Morneault, J. Pastor-Balbas. 

IETF RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACTIVE ASP ACTIVE 

AS Application Server 

ASP AS Process 

ASPSM Application Server Process State Maintenance 

BEAT heartBEAT 

BEAT ACK heartBEAT ACK 

CLDR ConnectionLess Data Response 

CLDT ConnectionLess Data Transfer 

COAK Connection AcKnowledge 

CODA Connection Oriented Data Acknowledge 

CODT Connection Oriented Data Transfer 

COIT Connection Oriented Inactivity Test 

CORE Connection REquest 

DAUD Destination state AUDit 

DAVA Destination AVAilable 

DRST Destination ReSTricted 

DUNA Destination UNAvailable 

DUPU Destination User Part Unavailable 

ERR ERroR 

IANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

IP Internet Protocol 

RESCO RESet COnfirm 

RESRE RESet REquest 

RFC Request For Comment (IETF standard) 

RIL Restricted Importance Level 

RKM Routing Key Management 

SCCP Signalling Connection Control Part 

SG Signalling Gateway 

SGP SG Process 

SS7 Signalling System Number 7 

SSC SCCP/Subsystem Congested 

SSN Subsystem Number 

SUA SCCP User Adaptation layer 



4 General considerations applicable to transport of 

Signalling System No. 7 over IP 

The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations 
in this clause are common to TS 102 141 [1 1], TS 102 142 [12] and the present document. 
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4.1 Transport protocol 



The protocol underlying the adaptation layer for transport of SS No. 7 signalling information in IP networks shall be 
SCTP. 

4.2 SCTP considerations 

The SCTP used shall conform to TS 102 144 [10]. 

The SCTP payload protocol identifier for messages pertaining to an adaptation layer shall be the one assigned by IANA 
for that layer. Adaptation layer messages received with neither the IANA payload protocol identifier nor payload 
protocol identifier equal to shall be silently discarded. 

Unordered user messages shall not be used. 

4.3 National options 

No national options excluded by ETSI standards shall apply to the present document. 

4.4 Application Server mode 

The Broadcast mode shall not be used. 

4.5 Application Server state handling 

If multiple Application Server Processes (ASPs) are used within the AS, the AS shall be considered active when the 
first ASP becomes active, and shall remain active until the last ASP becomes inactive. 

4.6 Dynamic registration 

Dynamic registration shall not be used for configuration management. The configuration of the system shall be 
modified only by the management system, and not by the protocol itself. 

4.7 Message distribution to the Application Server 

The key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than is allowed 
by the network management messages appropriate to that layer. 

4.8 Receipt of unrecognized messages 

If a message with an unrecognized message class is received, a Management Error message shall be returned with Error 
Code "Unsupported Message Class". 



5 General considerations applicable to SUA 

5.1 National options 

No national options excluded by EN 300 009-1 [1] and EN 300 008-1 [2] shall apply to the present document. 
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5.2 Dynamic registration 

Dynamic registration of Routing Keys shall not be used for configuration management. The configuration of the system 
shall be modified only by the management system, and not by the protocol itself. 

5.3 Message distribution to the Application Server 

The Routing Key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than 
Point Code + SSN. 

5.4 SUA procedures 

The SUA procedures shall be as defined in [3] augmented by ITU-T Recommendation Q.714 [4] as modified by 
EN 300 009-1 [1], except where otherwise defined below. 

5.5 Class 3 operation 

Class 3 operation is not in the scope of the present document. 



5.6 N-PCSTATE primitive 



The N-PCSTATE primitive's signalling point status parameter (see ITU-T Recommendation Q.71 1 [7] clause 6.3.2.2.5) 
has in [3] been extended to convey information about the restricted status of the signalling point. However, this shall not 
be used. 



Modifications to SUA-14 



Modificiations to [3] are listed according to the section or subsection of [3], 

Section 1 Introduction 

ANSI references do not apply. Add a reference "[ITU SCCP]". 

NOTE: SCCP user messages are transported between two signalling endpoints. 

Subsection 1.2 Terminology 

Routing Key: Dynamic registration of Routing Keys shall not be used for configuration management. The 
configuration of the system shall be modified only by the management system, and not by the protocol itself. 

Add the definition of Network Appearance taken from RFC 3332 [13] (which has been extended for SUA) viz: 

• "Network Appearance - The Network Appearance is an SUA local reference (typically an integer) shared by 
SG and AS that together with a Signalling Point Code or global title uniquely identifies an SS7 node by 
indicating the specific SS7 network it belongs to". 

Subsection 1.3.1 Protocol Architecture for Connectionless Transport 

NOTE: The entity labelled "SEP or STP" is just an SEP here since it contains an SCCP User. 

Subsection 1.3.1.1 

NOTE: The SG can act as an endpoint with messages routed to it also by global title, if the global title translation 
there yields the point code of the SG itself. 
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Subsection 1.3.1.2 SG as relay-point 



NOTE: Global Title Translation yields an "entity set", not an "entity". A way of viewing the AS is then as an 
"entity set", with each ASP that the AS uses viewed as an "entity" within the set. 

Subsection 1.3.2 Protocol Architecture for Connection-Oriented Transport 

Replace the first two sentences by: 

"In this architecture, the SCCP and SUA layers in the SGP interface to support connection-oriented data transfer 
between SEP and ASP. Connection sections are setup when routing the Connect Request messages from SEP via SGP 
to ASP or the other way". 

NOTE: The entity labelled "SEP or STP" is just an SEP here since it contains an SCCP User. 

Subsection 1.4.2 SCCP Protocol Class Support 

Protocol class 3 is not in the scope of the present document. 

Subsection 1.4.4 Interworking with SCCP Network Management Functions 

ANSI references do not apply. 

• N-STATE is defined in ITU-T Recommendation Q.711 [7], clause 6.3.2.3.2, table 16/Q.711. 

• N-PCSTATE is defined in ITU-T Recommendation Q.71 1 [7], clause 6.3.2.3.3, table 17/Q.71 1. 
N-COORD is defined in ITU-T Recommendation Q.71 1 [7], clause 6.3.2.3.1, table 15/Q.71 1. 

Subsection 1.4.5 Support for the management between the SGP and ASP. 

The SUA shall also provide interworking with SCCP management functions at the SG to inform concerned SCCP users 
in the SS No. 7 network about the availability, accessibility and congestion status of SUA/SUA users in the managed IP 
network. 

Subsection 1.5 Internal Functions Provided in the SUA Layer 

Transaction ID shall not be used for Routing Key Information. 

Dynamic registration shall not be used to provision Routing Key information. 

Subsection 1.5.1 Address Mapping at the SG 

Replace occurrences of "t (r)""by "T(r)". 

If messages are discarded when there is no address match, a report shall be made to Layer Management. 

Subsection 1.5.3 Address Mapping Function at a Relay Node 

It is preferable to route messages to the SG on Global Title within the SS No. 7 network, rather than on SSN (+ PC), if 
the relay function is to be invoked at the SG (with the SG's incoming SCCP itself performing a Global Title 
Translation). This helps the SG to avoid performing multi-point code working at its MTP level. 

If the relay function is to be invoked for messages from the IP network directly to the SS No. 7 network, resolution of 
the address information shall yield the information required in ITU-T Recommendation Q.714 [4], clause 2.2.2. 

Subsection 1.5.4 SCTP Stream Mapping 

A set of signalling messages requiring to be delivered in the same sequence as they are sent shall use the same SCTP 
stream. 

Sequenced delivery shall be used for SUA management messages. 

Protocol class 3 is not in the scope of the present document. 
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Subsection 1.5.6 Congestion Management 



How local and IP network congestion is reported to SUA is nodal implementation-dependent. But SUA shall be told if 
such congestion occurs. 

When an SG determines that the transport of SS7 messages is encountering congestion, the SG shall trigger SS7 SCCP 
Congestion messages to originating SS7 nodes according to the congestion procedures of ITU-T 
Recommendation Q.714 [4]. 

The triggering of SS No. 7 SCCP Management messages from an SG shall be done if congestion occurs. The means of 
doing this is a nodal implementation-dependent function. 

The SUA layer at an ASP or IPSP shall indicate local congestion to an SUA peer. 

When an SG receives a congestion message (SCON) from an ASP, and the SG determines that an endpoint. 

is now encountering congestion, it shall trigger congestion procedures as per ITU-T Recommendation Q.714 [4]. 

The receiving node shall be able to detect local congestion and inform the transmitting node of this, by whatever means. 

Subsection 1.6.1 Definition of the upper boundary 

ANSI references do not apply. 

Class 3 operation is not in the scope of the present document. If a connection request asks for class 3, and the node 
supports class 2 but not class 3, the class shall be lowered to 2 in the reply. 

N-EXPEDITED DATA and N-RESET pertain to class 3 operation, and are not in the scope of the present 
document. 

N-INFORM is defined in ITU-T Recommendation Q.711 [7], clause 6.1.1.3.2, table 8/Q.711. 

N-UNIT DATA is defined in ITU-T Recommendation Q.711 [7], clause 6.2.2.3.1, table 12/Q.711. 

N-NOTICE is defined in ITU-T Recommendation Q.71 1 [7], clause 6.2.2.3.2, table 13/Q.71 1. 

Add N-COORD, N-STATE and N-PCSTATE primitives, defined in ITU-T Recommendation Q.71 1 [7], 
clause 6.3.2, tables 14/Q.711, 15/Q.711, 16/Q.711 and 17/Q.711. 

Subsection 1.6.3 Definition of the Boundary between SUA and Layer Management 

Dynamic registration of RK shall not be used. 

Add the primitive M-ERROR_occ indication, in the direction SUA to LM, with purpose SUA reports an error condition 
to LM. 

Subsection 3.1 Common Message Header 

Replace the last paragraph with: 

• "Optional parameters shall occur at most once in an SUA message". 
Add another paragraph: 

• "The Reserved field shall be set to in messages sent, and shall not be examined on reception". 

Subsection 3.1.2 Message Classes 

MGMT messages shall use SCTP stream 0, SNM messages shall use stream 0, ASPSM messages shall use stream 
(apart from BEAT ACK which can use any stream), ASPTM messages shall use a traffic stream, CL and CO messages 
shall use any but stream 0. 

NOTE: Stream shall be used for SNM messsages, since DUNA, DAVA, DUPU messages referring-to the same 
destination must be delivered in the order in which they are sent, and DUNA and DAVA messages 
without SSN parameters can contain a list of destinations in their Affected Point Code parameter. The list 
in a DUNA or DAVA might contain some the same, and some different, destinations as a following 
DAVA or DUNA respectively. 
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The default Importance value for MGMT messages shall be 8 for NTFY and 7 for ERR. 

The default Importance value for SNM messages shall be 6 for DUNA, DAVA, DUPU, DAUD and SCON, it shall be 5 
for DRST. 

The default Importance value for ASPSM messages shall be 8 for all except BEAT ACK, which shall be 2. 

The default Importance value for ASPTM messages shall be 8. 

The default Importance values for CL and CO messages shall be the same as those defined in ITU-T Recommendation 
Q.714 [4] table 2/Q.714 for the equivalent messages. The maximum Importance values for CL and CO messages shall 
be the same as those defined in ITU-T Recommendation Q.714 [4] table 2/Q.714 for the equivalent messages. 

Routing Key Management messages shall not be sent. 

If a Routing Key Management message is received an Error (ERR) message shall be returned with Error Code 
"Unsupported Message Class", the RKM message shall be discarded and a report made to Layer Management. 

Subsection 3.1.3 Message Types 

Signalling network management messages: 

Destination Restricted (DRST) shall only be used when equivalent to an SCCP N-COORD primitive, but this is 
required only for separate nodes containing replicated subsystems, where these nodes also support SCCP management 
procedures. 

DRST equivalent to the SCCP N-PCSTATE indication primitive with Signalling point status parameter set to 
"destination restricted" shall not be sent. If such a N-PCSTATE primitive is received in the SUA, it shall be discarded 
and a report made to Layer Management. 

Application Server Process State Maintenance messages (ASPSM): 

Heartbeat is not required and BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If 
a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

Routing Key Management (RKM) Messages: 

These messages shall not be sent. If a Routing Key Management message is received an Error (ERR) message shall be 
returned with Error Code "Unsupported Message Class", the RKM message shall be discarded and a report made to 
Layer Management. 

Connection-Oriented messages: 

Reset Confirm, Reset Request and Connection Oriented Data Acknowledge messages are not in the scope of the present 
document. 

Subsection 3.2.1 Connectionless Data Transfer (CLDT) 

Message Priority is not required. 

SS7 Hop Count should be used. 

For protocol class messages, the sending SUA layer shall take into account the loading of SCTP streams when setting 
the Sequence Control parameter. 

Note that if a Segmentation parameter is present and its first/remaining segments field indicates more than one segment, 
the value of the Sequence Control parameter shall be the same (non-zero) value for all segments of the group (i.e. all 
segments with the same Segmentation Reference value, Source and Destination Addresses). 

Subsection 3.2.2 Connectionless Data Response (CLDR) 

The CLDR message shall be used if a message is returned from the node itself (conveyed in an N-NOTICE indication 
to SUA), in addition to its use when a node receives an (X)(L)UDTS message for onward transfer. 

Subsection 3.3.1 Connection Oriented Data Transfer (CODT) 

Message Priority is not required. 
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"NOTE *1" does not apply. 

DT2 and ED shall not be sent. If received they shall be discarded and a report made to Layer Management. 

Subsection 3.3.2 Connection Oriented Data Acknowledge (CODA) 

Does not apply. 

Subsection 3.3.3 Connection Request (CORE) 

Message Priority is not required. 

SS7 Hop Count should be used. 

Credit is not required. 

Sequence number is not required. 

If a CORE message is received with Protocol Class indicating class 3, and the node supports SCCP management 
procedures and class 2 but not class 3, the class shall be lowered to 2 in the COAK message sent in reply (see 
EN 300 009-1 [1], page 12 "Page 25, clause 3.1.3.1" and "Page 27, clause 3.1.5.1"). 

Subsection 3.3.4 Connection Acknowledge (COAK) 

Message Priority is not required. 

Credit is not required. 

For actions on reception of a COAK message for protocol class other than 2, see EN 300 009-1 [1], page 12 "Page 26, 
clause 3.1.4.2" and "Page 28, clause 3.1.5.2". 

Subsection 3.3.8 Reset Request (RESRE) 

Does not apply. 

Subsection 3.3.9 Reset Confirm (RESCO) 

Does not apply. 

Subsection 3.3.11 Connection Oriented Inactivity Test (COIT) 

Sequence Number is not required. 

Credit is not required. 

Subsection 3.4.1 Destination Unavailable (DUNA) 

SMI is not required. 

A DUNA message containing an SSN shall contain in the Affected Point Code parameter just one point code, that of the 
destination containing the unavailable subsystem. 

For DUNA messages not containing an SSN, it is optional to send an Affected Point Code parameter with more than 
one point code in it, but the ability to receive such a parameter is mandatory. The SG may limit the frequency at which 
it sends by the response method DUNAs referring to a particular destination, to 1 in the T8 interval of ITU-T 
Recommendation Q.704 [6], to give the receiver time to react. 

Subsection 3.4.2 Destination Available (DAVA) 

SMI is not required. 

A DAVA message containing an SSN shall contain in the Affected Point Code parameter just one point code, that of the 
destination containing the available subsystem. 

For DAVA messages not containing an SSN, it is optional to send an Affected Point Code parameter with more than 
one point code in it, but the ability to receive such a parameter is mandatory. 
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Subsection 3.4.3 Destination State Audit (DAUD) 



An ASP at a node that supports SCCP management procedures shall audit destination availability status by sending a 
DAUD message to the SGP. The interval for periodic audits is T10 (see ITU-T Recommendation Q.704 [6]). 

For DAUD messages not containing an SSN, it is optional to send an Affected Point Code parameter with more than 
one point code in it, but the ability to receive such a parameter is mandatory. 

An ASP at a node that supports SCCP management procedures shall audit subsystem availability status by sending a 
DAUD message to the SGP. The interval for periodic audits is T(stat.info) (see ITU-T Recommendation Q.714 [4]). 

The Affected Point Code parameter of this DAUD shall contain just one point code, that of the signalling point 
containing the unavailable subsystem. 

An ASP at a node that supports SCCP management shall audit the SUA/SCCP's availability status by sending a DAUD 
message to the SGP. The interval for periodic audits is T(stat.info) (see ITU-T Recommendation Q.714 [4]). 

The Affected Point Code parameter of this DAUD shall contain just one point code, that of the signalling point 
containing the unavailable SCCP. 

A DAUD message shall not be used to audit the restricted or congested status of a destination. 

A DAUD message shall not be used to audit the congested status of a subsystem. 

Subsection 3.4.4 Network Congestion (SCON) 

The SCON message MAY also be sent from the SUA layer of an ASP at a node that supports SCCP management 
procedures to an SUA peer indicating that the SUA layer or the ASP is congested (see clause 1.5.6). In this case, an 
extra Concerned DPC parameter shall be inserted into the SCON message, containing the point code of the originator of 
the message that triggered the SCON, taken from that message's Source Address. The Concerned DPC parameter shall 
contain one Concerned Destination Point Code field, a three-octet parameter padded on the left to the 24-bit boundary. 
Any resulting SCCP/Subsystem Congested (SSC) message from the SG shall be sent to the signalling point concerned 
using the Concerned DPC to populate the MTP label DPC of the SSC message. 

The Concerned DPC parameter shall be formatted as follows: 

12 3 

01234567890123456789012345678901 

I Tag = 0x0206 | Length = 8 | 

I reserved | Concerned DPC I 



If an SG receives an SCCP/subsystem congested message from an SS No. 7 node for delivery to an AS/ASP node that 
supports SCCP management, a SCON message containing an SSN (= 1) and a Concerned DPC parameter shall be sent 
to the node containing the AS/ASP. In this case, the Concerned DPC parameter shall equal the Affected DPC parameter 
and shall be the point code of the node sending the SSC message. 

For SCON messages where an SSN is not included (i.e. where the SCON equates to the SCCP N-PCSTATE Signalling 
point congested primitive), the Congestion Level Parameter shall be set to 0. In this case, the SCON indicates 
"congestion" of or towards a destination as in ITU-T Recommendation Q.704 [6] clause 13.6. Multiple Affected DPCs 
may be included in such a SCON message, but their inclusion shall not delay the sending of the SCON. 

For SCON messages where an SSN is included, the Affected Point Code parameter shall contain just one point code, 
that of the node containing the subsystem. 

Replace note 1 with: 

"NOTE 1 : When the SSN is included it must be equal to 1 . If the SSN is included but the optional Concerned DPC 
parameter is not included, the SCON corresponds to the N-PCSTATE primitive used to convey the 
Restricted Importance Level (RIL) to the SCCP user. If both the SSN and Concerned DPC parameters are 
included, the SCON corresponds to the SCCP/Subsystem Congested (SSC) message." 
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Subsection 3.4.5 Destination User Part Unavailable (DUPU) 

A DUPU message shall contain in the Affected Point Code parameter just one point code, that of the destination 
containing the unavailable User Part. 

Subsection 3.4.6 Destination Restricted (DRST) 

DRST equivalent to the SCCP N-COORD primitive is required if non-local replicated subsystems are used at nodes 
which support SCCP management procedures, as described in ITU-T Recommendation Q.714 [4], clause 5.3.5. 

In that case, the DRST message shall contain the Affected Point Code and SSN parameters. 

DRST messages equivalent to MTP "destination restricted" (TFR) (where the DRST does not contain an SSN 
parameter) shall not be sent. If a DRST indicating "restricted" is received, it shall be discarded and a report made to 
Layer Management. 

For a DRST message equivalent to the SCCP primitive N-COORD Request or Indication, the SMI parameter shall also 
be included, with value preferably 0. For a DRST message equivalent to the SCCP primitive N-COORD Response or 
Confirm primitive, the SMI parameter shall not be included. 

Subsection 3.5.5 Heartbeat (BEAT) 

Heartbeat is not required and BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If 
a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

Subsection 3.5.6 Heartbeat Ack (BEAT ACK) 

Heartbeat is not required. If a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

Subsection 3.6.1 ASP Active (ACTIVE) 

TID Label is not required. 

DRN Label is not required. 

Subsection 3.7.1 Error (ERR) 

The value of the Tag for the Network Appearance parameter shall be OxOlOD. 

Subsection 3.8 Routing Key Management (RKM) Messages 

RKM messages shall not be sent. If a Routing Key Management message is received an Error (ERR) message shall be 
returned with Error Code "Unsupported Message Class", the RKM message shall be discarded and a report made to 
Layer Management. 

Subsection 3.9 Common Parameters 

Heartbeat Data is not required. 

Registration Result, Deregistration Result, Registration Status and Deregistration Status shall not be used. 

Subsection 3.9.9 Heartbeat Data 

Heartbeat Data is not required. 

Subsection 3.9.11 Traffic Mode Type 

Broadcast Traffic Mode Type shall not be used. 

If an ASP ACTIVE or ASP ACTIVE ACK message is received indicating Broadcast Mode Traffic Type, an error 
message (ERR) shall be returned, with Error Code "Unsupported Traffic Handling Mode". 
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Subsection 3.9.12 Error Code 



The "Unexpected Message" error code may, depending upon ASP implementation, be used in an ERR message returned 
when a defined and recognized message is received unexpectedly (i.e. out of context). Alternatively, the ASP may 
discard the unexpected message, and not inform the SGP. In the latter case, it shall inform Layer Management. 

Use of the "Destination Status Unknown" error is deprecated where a D AUD requesting an audit of an unauthorized 
destination is received at an SG. Instead of sending an ERR message containing this Error Code, a DUNA message 
should be sent indicating "Destination Unavailable", and a report made to Layer Management. 

NOTE 1 : In any case there shall be no audit for the congestion or restriction status of a destination. 

Use of the "Subsystem Status Unknown" error is deprecated where a DAUD requesting an audit of an unauthorized 
subsystem is received at an SG. Instead of sending an ERR message containing this Error Code, a DUNA message 
should be sent indicating "Subsystem Unavailable", and a report made to Layer Management. 

NOTE 2: ITU-T Recommendation Q.714 [4] does not define procedures for auditing the congestion status of the 
SCCP or of subsystems, and such shall not be done. 

Subsection 3.9.17 ASP Identifier 

Delete the paragraph: 

• "The optional ASP Identifier parameter would contain a unique value that is locally significant among the 
ASPs that support an AS. The SGP shall save the ASP Identifier to be used, if necessary, with the Notify 
message (see section 3.3.3.2)." 

Subsection 3.9.18 Affected Point Code 

The ANSI 24 bit, and 16 bit, point codes shall not be used. 

The Mask parameter shall be set to 0. 

Subsection 3.9.19 Correlation ID 

Broadcast Mode shall not be used. 

Subsection 3.9.20 Registration Result 

Not applicable. 

Subsection 3.9.21 Deregistration Result 

Not applicable. 

Subsection 3.9.22 Registration Status 

Not applicable. 

Subsection 3.9.23 Deregistration Status 

Not applicable. 

Subsection 3.10 SUA-Specific parameters 

Credit is not in the scope of the present document. 

DRN Label, TID Label and Message Priority are not required. 

SMI is required only in the DRST message when that is equivalent either to the SCCP N-COORD Request or 
N-COORD Indication primitive. 

Note that the parameter SSN used in SNM messages is the same as Subsystem Number defined in subsection 3.10.2.5. 

Note that in subsection 3.10.12 defining the User/Cause parameter, it is named "Cause/User". 
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Subsection 3.10.2.2 Address Indicator 

As a clarification: 

• the Address Indicator for both the Source and Destination Addresses, for the direction SG to ASP, shall be 
coded: 



Sit 1 
Sit 2 
Sit 3 



0, no SSN included in SCCP party address 

1, SSN included in SCCP party address 

0, no PC included in SCCP party address 

1, PC included in SCCP party address 

0, no GT included in SCCP party address 

1, GT included in SCCP party address 



• the Address Indicator for the Source Address, for the direction ASP to SG, shall be coded: 

Bit 1 : 0, do not include SSN in SCCP calling party address when optional 
(i.e. RI != 2 or 4) 

1, include SSN 

Bit 2 : 0, do not include PC in SCCP calling party address 

1, include PC (the SG ' s own if none present in Source Address) 

Bit 3 : 0, do not include GT in SCCP calling party address if RI != 1 

1, include GT 

• the Address Indicator for the Destination Address, for the direction ASP to SG, shall be coded: 

Bit 1 : 0, do not include SSN in SCCP called party address when optional 
(i.e. RI != 2 or 4) 
1, include SSN (from global title translation if RI = 1 & GTT derives 
SSN, otherwise from Destination Address) 
Bit 2 : 0, do not include PC in SCCP called party address 

1, include PC (from Destination Address even if RI = 1) 
Bit 3 : 0, do not include GT in SCCP called party address if RI != 1 

1, include GT (from global title translation if RI = 1 & GTT modifies 
GT, otherwise from Destination Address) 

Subsection 3.10.2.3 Global Title 

Global Title type decimal 4 only shall be used. 

Translation Type, Numbering Plan and Nature of Address values shall be as defined in EG 201 693 [5]. 

Subsection 3.10.2.5 Subsystem Number (SSN) 

Subsystem Number values shall be as defined in EG 201 693 [5]. 

Subsection 3.10.2.7 Hostname 

The Host Name parameter is not required. 

Subsection 3.10.3 Destination Address 

For a clarification, see subsection 3.10.2.2. 

Subsection 3.10.6 SCCP Cause 

Reset Cause is not in the scope of the present document. 

ANSI references are not applicable. 

Subsection 3.10.7 Sequence Number 

P(R) and P(S) are not in the scope of the present document. 

Subsection 3.10.8 Receive Sequence Number 

Receive Sequence Number is not in the scope of the present document. 
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Subsection 3.10.9 ASP Capabilities 

Protocol class 3 is not in the scope of the present document. 

If protocol class 3 is requested, and the receiving node supports SCCP management procedures and class 2 but not 
class 3, then the class shall be lowered to 2 in the response. 

Subsection 3.10.10 Credit 

Credit is not required. 
Subsection 3.10.12 Cause / User 

Note that in messages using this parameter, and in subsection 3.10 listing the SUA-Specific parameters, this is referred 

to as "User/Cause". 

The value of the Length of the User/Cause parameter shall be 8. 

The User parameter, when referring to the SCCP, shall take only the value decimal 3. 

Subsection 3.10.13 Network Appearance 

The value of the Length of the Network Appearance parameter shall be 8. 

Subsection 3.10.15 DRN label 

Not required. 

Subsection 3.10.16 TID label 

Not required. 

Subsection 3.10.18 SMI 

SMI is required only in the DRST message when that is equivalent to the SCCP N-COORD Request or N-COORD 
Indication primitive. 

The SMI value shall then preferably be set to (see ITU-T Recommendation Q.713 [8], clause 5.2.3). 

Subsection 3.10.20 Message Priority (or Priority) 

Not required. 

Subsection 3.10.21 Protocol Class 

Class 3 is not in the scope of the present document. 

Subsection 3.10.22 Sequence Control 

Replace the reference with ITU-T Recommendation Q.71 1 [7], clause 6.2.2.2.2. 

Subsection 3.10.23 Segmentation 

The value of the Length of the Segmentation parameter shall be 8. 

Replace the description of the first / remaining segments field with: 



"bit 8 (MSB) 
bit 7 
bits 1-6 



indicates whether this is the first segment (1) or not (0) 
1 if the User requested class 1 in original message, else 
indicate the number of remaining segments, value to 15 



The field would thus be coded 1x00 0000 (first, no remaining segments) for a non-segmented CLDT, with x set to the 
class requested by the User. See ITU-T Recommendation Q.713 [8], clause 3.17. 

Note that all segments of a segmented message must themselves have sequenced delivery, whereas the User (for the 
original message before segmenting) might have requested class 0." 
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Subsection 3.10.24 Congestion Level 



The Congestion Level parameter of a SCON message equivalent to an SCCP N-PCSTATE "Signalling point congested" 
primitive shall be set to "0". 

Subsection 4.1.1 Receipt of Primitives from SCCP 

DUPU is the applicable SNM message when the SGP's SUA receives an SCCP N-PCSTATE indication primitive with 
Remote SCCP Status parameter set to "Remote SCCP unavailable, reason unknown" or "Remote SCCP inaccessible" or 
"Remote SCCP unequipped". 

DRST equivalent to the SCCP N-PCSTATE indication primitive with Signalling point status parameter set to 
"destination restricted" shall not be sent. 

Refer also to ITU-T Recommendation Q.714 [4], clause 2.2.1 for the SUA message distribution function, and to 
EN 300 009-1 [1], page 10 "Page 2, clause 1.1.2.2" (of ITU-T Recommendation Q.714 [4]). 

Broadcast Mode shall not be used. 

For an incoming SS No. 7 message with no, or partial, Routing Key match, if the message is discarded Layer 
Management shall be informed. 

Subsection 4.2 Receipt of Primitives from the Layer Management 

NOTE: Third paragraph, the ASP (not the SGP) or IPSP initiate the establishment of the SCTP association. 

Subsection 4.2.1 Receipt of SUA Peer Management Messages 

All ASP state changes shall be reported to the local Layer Management. 

"Transfer messages" and "data traffic" shall be understood to mean Connectionless and Connection-Oriented messages. 

Heartbeat is not required and BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If 
a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

ASPTM messages should be sent on one of the streams used to carry data traffic (i.e. Connectionless or 
Connection-Oriented messages) related to the Routing Context. 

Subsection 4.3.2 AS States 

AS and ASP configuration data shall be inserted by the management system, and shall not be created dynamically. 

If multiple Application Server Processes (ASPs) are used within the AS, the AS shall be considered active when the 
first ASP becomes active, and shall remain active until the last ASP becomes inactive. 

Subsection 4.3.4.1 ASP Up Procedures 

The ASP shall wait for the ASP Up Ack message before sending any other SUA messages (e.g. ASP Active). If the 
SGP receives any other SUA messages before an ASP Up message is received (other than ASP Down - see 
section 4.3.4.2), the SGP shall discard them. 

Subsection 4.3.4.2 ASP Down Procedures 

In the first paragraph, replace "DATA" with "Connectionless or Connection - Oriented". 
Replace "SSNM" with "SNM". 

The Registration procedures shall not be used. 

If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP shall now consider itself 
to be in the ASP-DOWN state. If the ASP were previously in the ASP- ACTIVE or ASP-INACTIVE state, the ASP 
shall then initiate procedures to return itself to its previous state. 

Subsection 4.3.4.3 ASP Active Procedures 

The terms "Data messages" and "traffic" within this subsection shall be understood to mean Connectionless and 
Connection - Oriented messages. 
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Once an ASP has received an ASP Up Ack, it shall send an ASP Active message to the SGP indicating that the ASP is 
ready to start processing Connectionless and Connection - Oriented messages. 

Multiple ASP Active messages may be used, within SCTP limits, to activate sets of Application Servers or Application 
Servers independently. 

If the SGP or IPSP receives any Connectionless or Connection - Oriented messages before an ASP Active message is 
received, the SGP or IPSP shall discard them. 

The ASP shall send Connectionless and Connection - Oriented messages only after receipt of the ASP Active Ack 
message for that Routing Context. 

If an "Out of the Blue" ASP Active message is received, it shall be discarded and a report made to Layer Management. 

Broadcast Mode shall not be used. 

If the traffic handling mode of the Application Server is not already known via configuration data, then the traffic 
handling mode in the first received ASP Active message causing the AS to transition to AS-ACTIVE shall be used to 
set the mode. 

The algorithm used in the SGP for load sharing Connectionless and Connection - Oriented messages within an AS 
across ASPs shall take into account message sequencing constraints. 

If multiple Application Server Processes (ASPs) are used within the AS, the SGP or IPSP shall direct Connectionless 
and Connection - Oriented messages received for the AS, as soon as it becomes active, to the first active ASP. 

Subsection 4.3.4.4 ASP Inactive Procedures 

The term "traffic" within this subsection shall be understood to mean Connectionless and Connection - Oriented 

messages. 

For a loadshare mode AS, when an ASP becoming inactive results in insufficient ASP resources being active in the AS, 
a Notify message shall be sent to all inactive ASPs. 

Broadcast mode shall not be used. 

Multiple ASP Inactive Ack messages MAY be used in response to an ASP Inactive message containing multiple 
Routing Contexts, within the SCTP limits. 

If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP shall now consider 
itself as in the ASP-INACTIVE state. If the ASP were previously in the ASP-ACTIVE state, the ASP shall then initiate 
procedures to return itself to that state. 

Subsection 4.3.4.5 Notify Procedures 

NOTE: Notify is used to report any AS state change (not just due to ASP failure). 

Broadcast Mode shall not be used. 

Subsection 4.3.4.6 Heartbeat Procedures 

Heartbeat is not required and BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If 
a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

Subsection 4.4 Routing Key Management Procedures 

Dynamic registration of Routing Keys shall not be used for configuration management. The configuration of the system 
shall be modified only by the management system, and not by the protocol itself. 

RKM messages shall not be sent. If a Routing Key Management message is received an Error (ERR) message shall be 
returned with Error Code "Unsupported Message Class", the RKM message shall be discarded and a report made to 
Layer Management. 
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Subsection 4.5.1 At an SGP 

Replace "SSNM" with "SNM" in the first paragraph. 

DRST equivalent to the SCCP N-PCSTATE indication primitive with Signalling point status parameter set to 
"destination restricted" shall not be sent. If such a N-PCSTATE primitive is received in the SUA, it shall be discarded 
and a report made to Layer Management. 

DUNA, DAVA, SCON, DUPU and DAUD messages shall be sent on SCTP stream 0. 

SCON, DUPU and DAUD messages shall not be sent un-sequenced. 

Subsection 4.5.2 At an ASP 

Replace "SSNM" with "SNM" throughout. 

Subsection 4.5.3 ASP Auditing 

Replace "SSNM" with "SNM" throughout. 

An ASP at a node that supports SCCP management procedures shall initiate an audit procedure to enquire of an SGP 
the availability of SS No. 7 destination(s) every T10 interval after the destination(s) become(s) unavailable, until receipt 
of the last corresponding DAVA message. An ASP shall not initiate an audit procedure for congested or restricted status 
of SS No.7 destination(s). 

A DAUD shall not be sent unsequenced and shall be sent in the following cases: 

• periodic (via T10); 

• isolation (ASP newly active/inactive). 

A DAUD message shall be replied-to with at least one DUNA or DAVA message, if the audit is authorized. A DUNA 
or DAVA in response to a DAUD shall contain 1 or a list of affected point codes. The maximum number of affected 
DPCs that can be included shall be in line with the SCTP limits. 

A SG may discard the received request, or it may respond with a DUNA if the ASP is not authorized to receive 
availability information of the concerned PC(s). 

An ASP at a node that supports SCCP management procedures shall initiate an audit procedure to enquire of an SGP 
the availability of the SUA/SCCP or an SUA/SCCP subsystem every T(stat.info) interval after the SUA/SCCP or 
subsystem becomes unavailable, until receipt of the corresponding DAVA message. An ASP shall not initiate an audit 
procedure for the congested or unequipped status of the SUA/SCCP or of SS No.7 subsystems. 

A DAUD shall not be sent unsequenced and shall be sent in the following cases: 

• periodic (via T(stat.info)); 

• isolation (ASP newly active/inactive). 

A DAUD message shall be replied-to with either a DUNA or a DAVA message, if the audit is authorized. If so, and if 
the audited subsystem is available, but it or its SUA/SCCP is congested, a SCON message shall also be returned after 
the DAVA message. 

A SG may discard the received request, or it may respond with a DUNA if the ASP is not authorized to receive 
availability information of the concerned subsystem. 

Subsection 4.6 MTP3 Restart 

Destination restricted shall not be used. 

The ASP shall audit the availability of unavailable destinations by sending DAUD messages. 

Subsection 4.7.1 Segmenting / Reassembly 

RESRE is not in the scope of the present document. 
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Subsection 4.7.2 Support for Loadsharing 

The use of the TID mechanism or the DRN mechanism is not recommended. . 

Subsection 4.7.3 Routing and message distribution at the SG 

The use of the TID mechanism or the DRN mechanism is not recommended. 

Subsection 5.1.1 Establishment of SUA connectivity 

If the link is the first to be aligned at the SG to the SEP, then an exchange of MTP TRA messages is required before the 
SSA is sent from the SG. 

Section 6 Security Considerations 

Security considerations are not in the scope of the present document. 

Subsection 7.1 SCTP Payload Protocol ID 

The Payload Protocol Identifier value "4" shall be used in each SCTP DATA chunk carrying SUA messages. 

Subsection 7.2 Port Number 

It is preferable that for server operation SCTP Port Number 14001 be used for SUA. SGPs may also use statically 
configured port numbers. 

Subsection 11.1 Normative (References) 

An additional reference is: 

"[21 19] RFC 2119 [14]: "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, 

March 1997." 

Subsection A.3.1 Connectionless Transport 

It is not necessary for the SGP of an SG used as a relay point to know the TID allocation policy within the AS across 
loadsharing ASPs in order for messages subsequent to the first (TC-BEGIN, not TC -Query for the present document) 
from origin to AS to be routed to the same ASP. It is sufficient that in the first TC-CONTINUE sent by the ASP in 
response to the TC-BEGIN, the ASP inserts in the SUA Source Address its own (unique) address (for GT routeing, its 
own GT [+SSN]). The TC at the transaction origin overwrites its initial called address (used in the TC-BEGIN message) 
with the calling address returned in the first TC-CONTINUE message. This is used in subsequent messages sent to the 
AS. 

ITU-T Recommendation Q.714 [4] clause 2.4 and ITU-T Recommendation Q.774 [9] clause 3.2.1.2, Dialogue 
Confirmation last 3 paragraphs refer. 
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Annex A (informative): 
Bibliography 

ITU-T Recommendation Q.715: "Signalling connection control part user guide". 
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